Cloud services claim to provide nearly everything you need without requiring you to run your own IT infrastructure. From e-mail and Web hosting to fully managed applications to vast on-demand computing resources, the cloud is shaping up to be one of the most important technology shifts in the last few years.

Sound too good to be true? Based on my experience over the last two years, I estimate that companies can easily offload 50 to 100 percent of their needs to cloud-based services with minimal business impact and near zero risk -- provided you follow the most basic best practices.

That said, not everything is easy, nor is the cloud right for everything. Certain technical requirements, such as very high performance with low latency, are challenging if not impossible. But there are a great many things that can be achieved at a lower cost and minimal risk.

There are three basic uses of the cloud's tech resources: computing power on-demand, (such as Amazon Web Services EC2 and S3 and Google App Engine); SaaS (software as a service) applications delivered over the Internet, such as Salesforce.com and NetSuite; and PaaS (platform as a service) application development and provisioning delivered over the Internet, such as Force.com.

As cloud offerings continue to mature, I am sure we'll see multiple iterations of the offerings, as well as many permutations. For example, I don't yet know where storage as a service fits, but there are multiple offerings for that, too.

Why I entrusted my own business to the cloud
I recently worked for an open source software company that had employees all over the world. That made us extremely dependent on technology to manage interpersonal relationships, all business functions, communications, and software development mechanics.

Having a geographically disperse team is not all it's cracked up to be. Even basic communications can be painfully difficult. If Skype were sketchy, development meetings could get set back an entire day. If e-mail were to go down, multiple business processes would require significant manual intervention. And if Salesforce.com was unavailable, we wouldn't have access to customer data for sales or support.

For the intrepid startup or IT department, the ability to outsource system operations to (theoretical) experts is very appealing, and most people are already comfortable with outsourcing certain elements such as Web servers and e-mail. And in companies with minimal IT staff, developers tend to help out with system administration.

Our goal was to not have to maintain physical machines or applications that weren't explicitly part of our development process. As a software company, we made the decision that our developers should be writing code, not performing system-administration tasks. But sadly, life isn't always that black and white. Our hosted systems and cloud services still required a modest amount of developer time, if for no other reason than the fact that they knew what they wanted the systems to do.

Development services in the cloud
To keep development smooth and not have to spend a ton of money on hardware, we moved all our development applications to Contegix, a managed hosting provider that supported the range of commercial and custom products we used. Our team also had access to the boxes so that every change didn't have to go through a trouble-ticket process (unless we wanted it to).

Having our development systems hosted seemed a bit strange to some people. But most got over that when they realized most developers are working off their own code branches, so they would simply merge the local and hosted pieces of code with the trunk that sits online.

We did run into a few hiccups. The integration of our development applications (Confluence, Jira, Bamboo, and custom code) was nonexistent, so there was a fair amount of work necessary for all the systems to interact properly. And somewhere down the line, one of our guys ordered some servers that we really didn't need. We ended up virtualizing them to the max for QA and testing.

Business apps in the cloud
Most of the cloud apps we used supported business needs, from hosting software for users to download to handling customer data. None of these were within our core competence, and we were glad to rely on someone else to manage them.

Web server and downloads. I remember an ugly day at work back in 1996 when someone kicked out the power-supply plug for the servers that ran all the Bell Labs and Lucent Web sites. People were running around the hallways in a panic. After that, I decided I never needed to host my own Web servers or DNS.

At my open source company, we stayed true to that conviction. We put our Web site and intranet at Rackspace because we had to deal with software downloads and needed a dedicated machine and enough bandwidth for things not to choke.

We eventually moved our product downloads to Amazon S3, where we didn't worry about administration, bandwidth, or anything else. And we spent less than $100 per month for 15,000-plus downloads. We did suffer once or twice when Amazon went down, but we were able to easily change our Web site to point to our main Web server to get the same file. If you have the luxury of occasional downtime, S3 can't be beat on price or performance.

We also started running demos of our software on EC2 that would expire based on an allotted time frame.

CRM. We tried SugarCRM first but got stuck early on by the lack of a customer-support portal module (it's since been added), so we chose Salesforce.com.

Salesforce.com is relatively easy to use -- but only after the initial three or so months of painful trial and error. In addition to the base functionality, we created a very simple customer portal and used the Salesforce.com APIs to pull the data into our look and feel. This was great until we learned that we had exceeded the number of API calls and were forced to upgrade to a more expensive package. Nonetheless, in more than two years, we didn't experience any downtime of note, nor did we lose any information.

E-mail. We made the decision from day one that we never wanted to run our own mail server. E-mail is critical to most businesses these days, and it was critical in our case because we had a worldwide development and support team, continuous integration and build servers, forums, blogs, and so on. With all that to handle, we simply didn't want to deal with the possibility of e-mail going down. Letting someone else handle our e-mail sounded great. And it was great -- except when it wasn't.

We changed e-mail providers four times in less than two years and made multiple attempts with managed IMAP, Zimbra, and Gmail before we finally got it mostly right. It all started with Rackspace's managed IMAP, which was fine -- except there was no calendaring, and as we grew, so did the need for shared calendars.

We switched to Zimbra in late 2006. But it ate several people's calendars and contacts. And although the Zimbra team was fantastic in helping us with our problems, it was becoming a bit too much to deal with. So we went back to IMAP at Rackspace but kept Zimbra running.

Later on, Rackspace began offering hosted Microsoft Exchange. I had been through the hosted Exchange nightmare at another company and refused to get involved in that ordeal again. Plus, for an open source company, it's weird to depend on Microsoft.

Then, like a shining star came Google Apps for our domain. So we switched again. Our first test-drive with Google Apps was all well and good for the first few days. Everyone felt OK about using POP and the Gmail interface, and we were reasonably sure that it wouldn't eat calendars as Zimbra had. What could go wrong?

As it turned out, plenty could go wrong. This was before Gmail supported IMAP, and the POP implementation turned out to have a few very bizarre quirks, such as the fact that you couldn't POP down e-mail that you sent to yourself, including CCs. Messages would disappear into the ether. And user management was a total nightmare; we had something like 40 aliases for lists that had to be entered individually.

It took all of five minutes before our developers freaked out. So we flipped the switch back to Zimbra. Mail delivery was still way more important than calendars, and Zimbra had come out with a new version that synced better and had a slick new UI. But Gmail offered massive storage, and most of our team liked the interface, so the move back to Zimbra left some folks pining for Google. That's why when Google came out with Google Apps Premier Enterprise (GAPE), we gave that a whirl.

GAPE ended up working quite well -- except for a few quirks (surprised?), such as the fact that if you use IMAP, you get this weird "All mail" folder that seems to never stop syncing on many versions of Mac Mail. But GAPE met all our requirements, including integration with Salesforce.com. Despite the occasional missing e-mail, we were sold.

I learned that e-mail and calendaring applications are the most personal apps people use, and thus the most difficult to unlearn or change. Your needs here will be driven by more than functional requirements.

Why I'm doing it all again at my new company
In the end, our jump to the cloud was based on a desire to avoid expensive, cumbersome infrastructure. While using cloud services was not without its challenges, I can absolutely say that I would do it again. And in fact, I already have: I'm running my new company in a very similar way with minimal capital expenditure for hardware and reliance on a variety of trustworthy providers to manage everything.

Yes, the cloud requires you to give up some control to get benefits. But as far as I can tell, the positives far outweigh the negatives.